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5 RELATED APPLICATIONS 

[0001] The present application is related to and claims priority from U.S. 
Provisional Applications No. 60/189,402 entitled "New Technique to Avoid G.HS 
False Start Due to FEXT," filed March 15, 2000, No. 60/199,788 entitled "New 
Technique to Avoid G.HS False Start Due to FEXT," filed April 26, 2000, 

10 No. 60/222,104 entitled "G.HS. BIS: Proposed Solutions to Avoid G.HS False 
Start/Connection Due to FEXT," filed July 28, 2000, and No. 60/222,064 entitled 
"G.HS. BIS: Proposed Solutions to Avoid G.HS False Start/Connection Due to FEXT 
(part II)," filed August 1, 2000, ail of which are hereby incorporated by reference in 
their entirety. 

15 FIELD OF THE INVENTION 

[0002] The present invention relates generally to modem communication and 
handshaking protocols and, more specifically, to improved connection methods 
using the G.HS protocol. 

BACKGROUND OF THE INVENTION 

20 [0003] The Telecommunications Standards Section of the International 
Telecommunication Union (sometimes designated as ITU-T) provides 
recommendations to facilitate the standardization of the telecommunications 
industry. ITU-T recommendation G. 994.1 (often referred to as G.HS) defines a 
handshaking protocol where preliminary information is exchanged between a 

25 central office transceiver and a remote transceiver. In general, this handshaking 
protocol defines the transceivers' capabilities and parameters for the connection 
between them. Recommendation G.994.1 is herein incorporated by reference in its 
entirety. The G.HS protocol employs multiple tones in parallel to give resilience in 
the presence of interference, whereas earlier handshaking techniques used a single 

30 tone and were susceptible to external interference. For instance, the single tone 
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could be displaced by interference thereby preventing handshaking from 
proceeding. Given the robust nature of G.HS, it has been a very popular 
handshaking protocol and it has been widely implemented. 

[0004] Field experience has shown, however, that G.HS connections are 
5 sometimes affected by cross talk interference. Cross talk is present in data 
transmission when two wires are close enough to each other that one of them 
generates energy in the other due to coupling. Two potential types of cross talk 
coupling are generally referred to as near-end cross talk (NEXT) and far-end cross 
talk (FEXT). Given the robust nature of the G.HS protocol (despite FEXT being a 
10 relatively weak signal), FEXT of G.HS. signals may cause false triggering of 

connections in adjacent lines. In addition, FEXT of G.HS. signals may cause G.HS 
connections to be established between different pairs in a cable bundle. 

[0005] To avoid FEXT false connections, a modification to the G.HS protocol 
may be used to indicate the busy or idle status of the upstream channel during 

15 establishment of a G.HS session. This modified protocol superimposes a busy 
signal on existing tones from the modem to create busy tones. For reference, the 
modem may be referred to as a Central Office (CO) modem, the tones as C- 
TONES, and the busy tones as C-TONES-BUSY. C-TONES-BUSY enables the 
CO modem to indicate if it is initiating the handshake or if it is responding to a 

20 remote terminal (RT) modem that is initiating the handshake. 

[0006] G.HS allows the RT modem to indicate if it is initiating or responding. If 
initiating, the RT modem sends a request signal that may be referenced as R- 
TONES-REQ. If responding, the RT modem sends a response signal that may be 
referenced as R-TONE1. 

25 [0007] In operation, a CO modem initiates a session using C-TONES signals. 
The RT modem on the primary line responds with R-TONE1 . RT modems on 
adjacent lines may receive the C-TONES signals due to FEXT and respond with R- 
TONE1 . CO modems on adjacent lines are expecting the R-TONES-REQ signal 
and thus do not communicate. When a RT modem initiates a session, it sends a R- 
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TONES-REQ signal. The CO modem on the primary line responds with C-TONES- 
BUSY. CO modems on adjacent lines may receive the R-TONES-REQ signal due 
to FEXT and respond with C-TONES-BUSY as well. RT modems on adjacent lines 
recognize the C-TONES-BUSY signal as a response and do not communicate. 

5 [0008] The modification to the G.HS signaling protocol by the CO and RT 
modems helps to prevent the inadvertent initiation of G.HS sessions in adjacent 
wire pairs due to FEXT. The modified signaling protocol further reduces signal 
collision when multiple G.HS RT modems reside on the same telephone line. This 
signaling protocol requires that CO modems transmit C-TONES-BUSY in response 

10 to R-TONES-REQ. The CO modem does not respond to R-TONE1 unless it just 
transmitted C-TONES. The RT modem does not respond to C-TONES-BUSY 
unless it just transmitted R-TONE-REQ. 

[0009] Although the modified G.HS signaling protocol reduces the likelihood of 
false starts due to FEXT, it is still problematic. For example, assume that a RT 

15 modem initiates and sends R-TONES-REQ and a CO modem responds with C- 
TONES-BUSY. Due to FEXT, other CO modems may respond with C-TONES- 
BUSY. Only the initiating RT modem responds with R-TONES1 . Other adjacent 
RT modems will not respond since they receive the C-TONES-BUSY and know that 
they did not initiate the session. A problem associated with this first scenario is that 

20 the RT modem may receive the desired C-TONES-BUSY signal as well as FEXT C- 
TONES-BUSY signals. If a FEXT C-TONES-BUSY signal comes before the 
desired C-TONES-BUSY, the initiating RT modem may start communicating with 
the wrong CO modem. Moreover, this communication may be disrupted by the true 
and stronger C-TONES-BUSY signal, thereby causing the G.HS handshake to fail. 

25 This process may repeat. 

[0010] Another problem occurs if the true C-TONES-BUSY signal is not received 
for some reason. This may happen, for example, if the CO modem is disconnected. 
As a result, a false connection with an adjacent CO may be established due to 
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FEXT. Yet another problem is that the RT modem may continue a handshake with 
multiple CO modems for a certain time period before terminating the process. 

[0011] In a second scenario, assume the CO modem initiates a handshake 
session by sending C-TONES. RT modem responds with R-TONE1. Adjacent RT 
5 modems may receive C-TONES due to FEXT and respond with R-TONE1 . The CO 
modem responds to a received R-TONE1 by sending a response signal that may be 
referred to as C-GALF1 . Other adjacent CO modems will not respond since they 
receive R-TONE1 instead of R-TONES-REQ. A problem associated with this 
scenario is that the initiating CO modem may receive the desired R-TONE1 signal 
10 as well as FEXT R-TONE1 signals. If a FEXT R-TONE1 signal comes before the 
desired R-TONE1, the CO modem starts communicating with the wrong RT 
modem. This communication may be disrupted by the true R-TONE1 thereby 
causing the G.HS session to fail. 

[0012] Another problem is that the CO modem may not receive the true R- 
15 TONE1 for some reason. In such a case, a connection with an adjacent RT may be 
established through FEXT. Yet another problem is that the CO modem may 
undergo a handshake session with multiple RT modems for an undue period of 
time. 

[0013] Thus, signaling methods with the G.HS protocol are only partially effective 
20 in reducing G.HS false connections in adjacent lines. Completion of a desired G.HS 
handshake session is not guaranteed since such completion may be affected by 
false responses from a remote end of an adjacent line. Furthermore, if a desired 
remote end does not respond for some reason, communication through FEXT may 
commence. There is a need, therefore, for improved methods for reducing false 
25 starts due to FEXT. 

SUMMARY OF THE INVENTION 

[0014] The present invention provides systems, methods, and devices that 
overcome the above-described problems and disadvantages. In one embodiment of 
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the present invention, a local transceiver commences communications with a remote 
transceiver by generating a request signal to initiate a handshake session. The 
request signal includes an identification unique to the remote transceiver. The 
remote transceiver receives the request and verifies the identification. The remote 
5 transceiver then sends a response with an identification unique to the local 
transceiver. The local transceiver receives the response and verifies the 
identification before completing the handshake session. The present invention 
prevents false starts due to FEXT by requiring verification of the device receiving 
signals during the handshake session. Devices on adjacent wires fail to verify the 
10 identification and thus will not respond. In this manner, the method ensures that 
only the desired device will respond. 

[0015] These and other features and advantages of the present invention will 
become fully apparent by examination of the following detailed description and the 
accompanying drawings. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] Non-limiting and non-exhaustive embodiments of the present invention are 
described in the Figures, in which: 

[0017] FIG. 1 is a block diagram illustrating a method for performing a handshake 
session between a central office device and a remote terminal device in accordance 
20 with one embodiment of the present invention; 

[0018] FIG. 2 is a flow diagram illustrating the method of FIG. 1 ; 

[0019] FIG. 3 is a block diagram illustrating a method for performing a handshake 
session between a remote terminal device and a central office device in accordance 
with one embodiment of the present invention; 

25 [0020] FIG. 4 is a flow diagram illustrating the method of FIG. 3; 
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[0021] FIG. 5 is a table illustrating code points of an identification field by which a 
CO or RT device may indicate they support service identification in accordance with 
one embodiment of the present invention; 

[0022] FIGS. 6A, B and C are tables illustrating octets of an identification field 
5 that specify a service identifier in accordance with one embodiment of the present 
invention; and 

[0023] FIG. 7 is a flow diagram illustrating a method for performing a handshake 
session between a local device and a remote device in accordance with one 
embodiment of the present invention. 

10 DETAILED DESCRIPTION OF THE INVENTION 

[0024] Reference throughout this specification to "one embodiment" or "an 
embodiment" means that a particular feature, structure, or characteristic described in 
connection with the embodiment is included in at least one embodiment of the 
present invention. Thus, the appearances of the phrases "in one embodiment" or "in 
15 an embodiment" are not necessarily all referring to the same embodiment. 
Furthermore, the particular features, structures, or characteristics may be combined 
in any suitable manner in one or more embodiments. 

[0025] As referenced herein the term device may include a modem or any other 
communication device capable of performing a handshake session using known 
20 protocols (e.g., transceiver). In addition, a CO or RT device may be stated 
throughout the specification. However, a CO or RT device may also be referenced 
interchangeably as a local device or a remote device. A local device may be a 
device that initiates a handshake session and a remote device may be a device that 
responds to the initiation. 

25 [0026] Referring now to FIG. 1, there is shown a block diagram illustrating a 
method for performing a handshake session between a central office device and a 
remote terminal device in accordance with one embodiment of the present invention. 
A central office (CO) device 10 is shown initiating a request 12 with a remote 
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terminal (RT) device 14. In one embodiment, the methods disclosed herein are 
used in a G.HS protocol environment. However, one of skill in the art will recognize 
that the techniques disclosed herein may be employed using other protocols as well. 

[0027] The request 12 includes a RT identification 16 that may be embodied, for 
5 example, as an identification signal. The RT identification 16 is unique to the RT 
device 14. In the G.HS protocol, the request 12 may be identified as C-TONES. 
The RT device 14 receives the request 12 and verifies that the RT identification 16 is 
correct before sending a response. Due to FEXT, RT devices 18 on adjacent lines 
may receive the request 12 and the RT identification 16. The adjacent RT devices 
10 1 8 verify the RT identification 1 6. Because the RT identification 1 6 is not correct, the 
adjacent RT devices 18 do not respond. 

[0028] As can be seen, the RT device 14 responds with a response 20. The 
response 20 may be referred to as R-TONE1 in the case of G.HS protocol. 
Response 20 may include a CO identification 22 unique to the CO 10. Note, 

15 however, that the use of CO identification 22 is not necessary in the case of G.HS 
protocol. This is because the response 20 (R-TONE1) is different from the RT 
initiating signal (R-TONE-REQ), which will be discussed in reference to Figures 3 
and 4. Thus, a response 20 not associated with a CO identification 22 will not false- 
trigger adjacent CO devices 24 in operating under the G.HS protocol. For the sake 

20 of complete discussion, however, this example assumes a CO identification 22 is 
associated with the response 20. 

[0029] The CO device 10 receives the response 20 and the CO identification 22. 
Upon confirmation of the CO identification 22, the CO device 10 continues with the 
handshake session until completion. CO devices 24 on adjacent lines may also 
25 receive the response 20 and the CO identification 22 due to FEXT. The CO devices 
24 verify the CO identification 22 and, upon confirming that the CO identification is 
incorrect, do not respond. In this manner, false starts are avoided by devices 18, 24 
on adjacent lines. 
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[0030] Note that in one embodiment, the RT identification 16 and the CO 
identification 22 are the same and provide a unique identification for the device pair 
formed by CO device 10 and RT device 14. However, RT identification 16 and CO 
identification 22 need not be the same so long as they uniquely identify the RT 
5 device 14 and the CO device 10, respectively. 

[0031] Figure 2 shows a flow diagram 200 illustrating a method for performing a 
handshake session between a central office device and a remote terminal device in 
accordance with one embodiment of the present invention. CO and RT 
identifications 16,22 are generated 202. These identifications 16,22 (also referred to 
10 as service identifiers) are unique to the CO and RT devices 10,14. In one 
embodiment, CO and RT identifications 16 and 22 are the same. Other CO-RT 
O device pairs included in the same cable bundle would each have a unique service 
m identifier as well. The identifications 16,22 may be established during installation of 

■its "a* 

t: the devices. For example, the service provider for that particular device pair may 

-5 15 choose identifications 16,22 and then inform the customer of same during 

fill 

ffji installation, or vice-versa. 

O [0032] In one embodiment, the last 4 digits of the associated POTS number may 
y. be used for identifications 16,22 so that they can be readily communicated between 

y the CO and RT devices 10,14. In the case where POTS numbers are not available, 
I* 20 identifications 16,22 may be randomly or systematically selected (e.g., by a random 
number generator or the service provider). Note that multiple service providers may 
service the same cable bundle. Thus, a relatively large identification space can be 
used to ensure that adjacent device pairs have different identifications 16,22. For 
example, the identifications 16,22 can be a six bit binary number so that there are 64 
25 different identifications (e.g., sufficient to support 50 device pairs for a given cable 
bundle). 

[0033] The number of bits may be increased to further reduce the likelihood of 
duplicate identifications for wires in a particular bundle. For example, the 
identification may be a sixteen bit binary number (or four digit decimal number), so 



8 



that the chance of adjacent device pairs in the same cable bundle having the same 
identifier is minimal. Thus, two conditions must be satisfied for a false connection to 
be established: more than one device pair must be assigned the same identification, 
and the two device pairs having the same identification must be adjacent. As such, 
5 a false connection is very unlikely. 

[0034] The CO device 1 0 initiates 204 a handshake session by sending a request 
12. This request 12 includes or is otherwise associated with the RT identification 16. 
The RT device 14 receives 206 the request 12. The RT device 14 then determines 
208 if the received RT identification 16 is correct. If the RT identification 16 is not 

10 correct (e.g., it does not match the service identifier associated with RT 14), then the 
RT device 14 remains 212 silent thereby avoiding a false connection. However, if 
the RT identification 16 is correct (e.g., it matches the service identifier associated 
with RT 14), then the RT device 14 generates 210 a response 20. The response 20 
may include or be otherwise associated with a CO identification 22. Recall, 

15 however, that in protocol environments such as G.HS or the like, the CO 

identification 22 is not necessary as previously explained. Thus, steps related to 
generation, detection and verification of CO identification 22 may be skipped in such 
environments. 

[0035] The CO device 10 receives 214 the response 20 and CO identification 22 
20 from the RT device14. The CO device 10 then determines whether the CO 

identification 22 associated with response 20 is correct (e.g., whether it matches the 
service identifier associated with CO 10). If so, the CO device 10 completes 218 the 
handshake session with the RT device 14 thereby establishing a valid connection 
between CO device 10 and RT device 14. However, if the CO identification 22 
25 associated with response 20 is not correct, then the CO device 1 0 remains 212 
silent thereby avoiding a false connection. 

[0036] Note that adjacent RT devices (e.g., RT device 1 8) may receive FEXT 
versions of request 12, but do not respond because the RT identification 16 is not 
the correct service identifier for those adjacent RT devices. Similarly, note that 
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adjacent CO devices (e.g., CO device 24) may receive FEXT versions of response 
20, but do not respond because the CO identification 22 is not the correct service 
identifier for those adjacent CO devices. 

[0037] Referring to Figures 3 and 4, a block diagram and accompanying flow 
5 diagram 400 are shown to illustrate a method in accordance with one embodiment of 
the present invention where the RT device 14 initiates the handshake session. As 
before, identifications 16, 22 are uniquely generated 402 for the CO device 10 and 
the RT device 14 pair. The above discussion describing how identifications 16, 22 
are established and their various possible forms equally applies here. The RT 
w device 14 initiates 404 the handshake session by sending a request 12. Request 12 
may be referred to as a R-TONE-REQ in the case of the G.HS protocol. Request 12 
includes or is otherwise associated with the CO identification 22. The CO device 1 0 
receives 406 the request 12 and the CO identification 22. 

[0038] The CO device 10 determines 408 whether the CO identification 22 is 
15 correct (e.g., whether it matches the service identifier associated with CO 10). If the 
CO identification 22 is not correct, then the CO device 24 remains 412 silent. 
However, if the CO identification 22 is correct, then the CO device 10 generates 410 
a response 20. Response 20 may be referred to as a C-TONES in the case of the 
G.HS protocol. Response 20 includes or is otherwise associated with the RT 
20 identification 1 6. The RT device 14 receives 414 the response 20 and the RT 
identification 16. 

[0039] The RT device 14 determines 41 6 whether the received RT identification 
16 is correct (e.g., whether it matches the service identifier associated with RT 14). 
If the RT identification 16 is correct, then the RT device 14 completes 418 the 
25 handshake session with the CO device 10 thereby establishing a valid connection 
between RT device 14 and CO device 10. However, if the RT identification 16 is not 
correct, then the RT device 18 remains 412 silent thereby avoiding a false 
connection. 
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[0040] Note that adjacent CO devices (e.g., CO device 24) may receive FEXT 
versions of request 12, but do not respond because the CO identification 22 is not 
the correct service identifier for those adjacent CO devices. Similarly, note that 
adjacent RT devices (e.g., RT device 18) may receive FEXT versions of response 
5 20, but do not respond because the RT identification 16 is not the correct service 
identifier for those adjacent RT devices. 

Modulated Service Identifier 

[0041] The service identifiers (e.g., identifications 16, 22) may be carried or 
incorporated within the response and request signals 12, 20. This may be 
10 accomplished, for example, by modulating the amplitude of the signals 12, 20 to 
include the service identifiers. Amplitude modulation is advantageous in that it is 
backward compatible for devices not supporting the techniques of the present 
invention. 

[0042] Per the G.HS protocol, R-TONE-REQ (e.g., the RT request 12) has a 
15 phase reversal every 16 ms. A particular amplitude level for each 16 ms duration 
may be used to transmit 1 bit of the corresponding service identifier. For example, 
six 16 ms periods could be used to transmit a 6 bit service identifier. Likewise, 
sixteen 16 ms periods could be used to transmit a 16 bit service identifier. A logical 
ONE bit may be represented by a bigger amplitude A1 , and a logical ZERO may be 
20 represented by a smaller amplitude A2. Thus, a message specifying the service 
identifier can be communicated by a RT device using the modulation scheme. 
Because the service identifier may vary greatly, the average power will also vary. In 
one embodiment, A1=1 (nominal signal amplitude level) and A2=0.75 (3/4 of 
nominal signal amplitude level). In such an embodiment, note that if the service 
25 identifier has more logic ZERO bits, the average power will be slightly lower. 

[0043] To indicate the beginning of the message including the service identifier, a 
unique header is added before service identifier. By way of example, the header 
may consist of a string of bits such as 1 1 1 1 1 1 1 1 0. Thus, a local device may send a 
request having the message 1111111 Oxxxxxxxxxxxxxxxx within, where 
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"xxxxxxxxxxxxxxxx" reflects a unique 16 bit service identifier of the associated 
device or device pair. Likewise, a tail can be added to indicate the end of the 
message. For example, the tail may consist of 01 . Thus, a local device may send a 
request having the message 11111 1 10xxxxxx01 within, where "xxxxxx" reflects a 
5 unique 6 bit service identifier of the associated device or device pair. The R-TONE- 
REQ (e.g., the RT request 12) is repeatedly sending the message. Since phase 
reversal is still included, the technique is backwards compatible. 

[0044] The same modulation scheme can be applied to C-TONES (e.g., CO 
request 12) to carry the service identifier when the CO device initiates the 

10 handshaking session. Thus, no matter which side initiates the handshaking session, 
only the remote modem on the same line will respond. Phase reversal is not applied 
to C-TONES and backwards compatibility is therefore not an issue. The 
identification carried in the request and the response confirms the right connection 
and prevents false connections due to FEXT. Note that the detection of the service 

15 identifier may be made optional, and can be bypassed if so desired. Thus, the 
present invention provides a backwards compatible solution. 

[0045] One skilled in the art will recognize alternative methods for incorporating 
an service identifier within a signal in light of this disclosure, and such alternate 
methods are intended to be within the scope of this invention. For example, an 
20 alternative scheme is to carry the service identifier in signals or tones other than, or 
in addition to, the R-TONE-REQ and C-TONES signals. In one embodiment, an 
additional tone can be used to represent a logical ONE, and no additional tone can 
be used to represent a logical ZERO. 

[0046] An alternative modulation method is to use differential phase reversal. In 
25 such an embodiment, a logical ONE might be represented with phase reversal, while 
a logical ZERO might be represented without phase reversal. In this way, the 
average power is always the same. Note, however, that the regular phase reversal 
in R-TONE-REQ is sometimes non-occurring, although it occurs in most time 
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periods given many logical ONEs in the header and tail of a service identifier 
message. 

[0047] Another alternative modulation method is to use frequency modulation. In 
such an embodiment, a logical ONE might be represented with a first frequency 
5 (e.g., nominal - 1 KHz), while a logical ZERO is represented with a second 
frequency (e.g., nominal + 1 KHz). Those skilled in the art will recognize other 
modulation techniques that can be employed in light of this disclosure. 

Code Point for Service Identifier 

[0048] During a G.HS connection session, some message bits are exchanged. 

10 In one embodiment, the service identifier can be exchanged as part of a G.HS 

message to confirm the correct connection, or to exchange the service identification. 
Referring to Figure 5, a table is shown that incorporates code points within an 
Identification Field. The added code points indicate that the device supports the 
identification methodology of the present invention ("service identifier information"). 

15 The message may be exchanged during the handshake protocol at the Spar(1 ) level 
of the Identification Field. 

[0049] Referring to Figures 6A-6C, three tables are shown that represent three 
octets for an Npar(2) level of the Identification Field. As previously stated, a service 
identifier in accordance with one embodiment of the present invention may be 

20 represented by 16 bits. This service identifier may be exchanged during the 
handshake protocol at the Npar(2) level of the Identification Field using the 
illustrated three octets as shown. Note that the service identifier may be exchanged 
at other parameter levels, and may be based on other definitions (e.g., 6 bit). The 
present invention is not intended to be limited to any one particular embodiment 

25 disclosed herein. Other embodiments will be apparent to one skilled in the art in 
light of this disclosure. 

Service Identifier Setup 

[0050] Referring to Figure 7, a flow diagram 700 illustrating a method for 
performing a handshake session between a local device and a remote device in 
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accordance with one embodiment of the present invention is shown. In this method, 
a unique service identifier for a local device is automatically delivered to a remote 
device after installation. The local device may be an RT or CO device, but for 
purposes of explanation is selected as an RT device. The remote device is selected 
5 as a CO device. Nevertheless, the method is equally applicable to installation of a 
CO device. 

[0051] The method commences with the installation 702 of the RT device, or 
local device. During the installation, the system provider or customer generates 704 
an identification number. The identification number may be based on a service 
10 mechanism, such as a corresponding POTS number, random selection process 
(e.g., random number generator), or other identification selection methodology. 

[0052] Upon an initial communication between the RT device and the CO device, 
the RT device automatically transmits 706 the identification number to the CO 
device. This initial communication may be flagged or otherwise identified as a new 

15 installation or as a new user transfer. In one embodiment, the RT device transmits 
the identification number within a carrier signal in code point as defined above with 
reference to Figures 5, 6A, 6B and 6C. The CO device receives and stores 708 the 
identification number (e.g., in a computer readable memory). The process may 
continue with either the RT device or the CO device initiating a subsequent 

20 handshake session. 

[0053] The remaining steps 710-724 are as outlined in the flow diagram of Figure 
2 and outline a subsequent handshake session wherein service identifiers are 
exchanged and verified. Note that the initial communication between a local device 
and a remote device may be vulnerable to FEXT. However, the likelihood that other 
25 devices on adjacent pairs are undergoing installation at the same time is very small. 
Labeling the initial communication as a new installation identification transfer or a 
new user transfer will reduce false starts to an acceptably low probability of 
occurrence. Devices on adjacent pairs will not be expecting a new user or new 
installation and will be programmed not to respond. 
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[0054] In summary, the present invention can be used to prevent false starts due 
to interference (e.g., FEXT) between modems undergoing a handshake session. 
Identifications are provided to devices on opposing sides to provide verification. 
Response and request signals include the identifications to ensure that only the 
5 correct and desired device responds. Devices on adjacent wires remain silent and 
do not interfere with the communication. 

[0055] The above description of illustrated embodiments of the invention is not 
intended to be exhaustive or to limit the invention to the precise forms disclosed. 
While specific embodiments of, and examples for, the invention are described herein 
10 for illustrative purposes, various equivalent modifications are possible within the 
scope of the invention, as those skilled in the relevant art will recognize. 

[0056] These modifications can be made to the invention in light of the above 
detailed description. The terms used in the following claims should not be construed 
to limit the invention to the specific embodiments disclosed in the specification and 
15 the claims. Rather, the scope of the invention is to be determined by the following 
claims, which are to be construed in accordance with established doctrines of claim 
interpretation. 
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